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PREFACE 


Because  of  funding  limitations,  the  Air  Force  terminated  the  effort 
which  this  document  describes  before  the  effort  reached  its  log- 
ical conclusion.  This  specification  has  not  been  formally  approved 
but  was  published  in  the  interest  of  capturing  and  disseminating 
the  computer  security  technology  that  was  available  when  the  effort 
was  terminated. 

This  specification  was  to  describe  the  characteristics  of  a secure 
general  purpose  computer  system  (namely  Multics)  based  upon  a 
security  kernel.  A previous  Air  Force  sponsored  project  to  develop 
security  controls  for  an  operational  Air  Force  computer  system 
served  as  a background  and  starting  point  for  the  effort  that  was 
to  be  described  here.  However,  the  Air  Force  terminated  the  effort 
to  be  reported  before  the  results  could  be  documented  and,  con- 
sequently, much  of  the  information  found  in  this  report  is  drawn 
from  the  documented  results  of  the  previous  project.* 

*¥hitmore,  J.  et  al,  "Design  for  Multics  Security  Enhancements" 
Honeywell  Information  Systems,  Inc.,  ESD-TR-74-176,  December  1973. 


SECURITY  CLASS’FlCATION  OF  THIS  °4GE  (When  Data  Entered) 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMDER  j2.  GOVT  ACCESSION  NO. 

ESD-TR-76-357  | 

3.  RECl°'  FN'T'S  CATALOG  NUMBER 

4.  TITLE  ( and  Subtitle) 

PROTOTYPE  SECURE  MULTICS  SPECIFICATION 

S.  TYFE  OF  REPORT  ft  PERIOD  COVERED 

6.  PERFORMING  ORG.  REPORT  NUMBER 

7.  AUTHORfaJ 

3.  CONTRACT  OR  GRANT  NUMBERfsJ 

FI9628-74-C-0I93 

9.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

Honeywell  Information  Systems,  Incorporated 

Federal  Systems  Operations 

7900  Westpark  Drive,  McLean,  VA  22 101 

10.  PPOGPAM  ELEMENT,  PROJECT,  TASK 

A PEA  A WORK  UNIT  NUMBERS 

11.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Deputy  for  Command  and  Management  Systems 

Electronic  Systems  Division 

Hanscom  Air  Force  Baser  MA  0f73f 

12.  REPORT  DATE 

January  1976 

13.  NUMBER  OF  PAGES 

42 

14.  MONITORING  AGENCY  NAME  & ADDRESS  (if  different  from  Controlling  Office) 

IS.  SECURITY  CLASS,  (of  this  report; 

UNCLASSIFIED 

ISa.  DECLASSI  FlC  ATI  ON/ DOWN  GRADING 

SCHEDULE 

N/A 

16.  DISTRIBUTION  STATEMENT  (of  this  Report) 

Approved  for  Public  Release;  Distribution  Unlimited. 

17.  DISTRIBUTION  STATEMENT  (of  the  abstract  entered  In  Block  20,  If  different  from  Report) 

IS.  SUPPLEMENTARY  NOTES 

19.  KEY  WORDS  (Continue  on  reverse  side  Ifnecessary  and  identify  by  block  number) 

Security,  Security  Kernel,  Multics,  Multilevel  Security 

20.  ABSTRACT  (Continue  on  reverse  side  if  necessary  and  Identify  by  block  number) 

The  goal  of  Project  Guardian  is  to  design,  develop  and  certify 
a secure  Multics  to  provide  a certified  secure  multilevel  compu- 
ter utility.  This  report  covers  preliminary  work  in  develop- 
ment of  a specification  describing  the  characteristics  of  the 
secure  system. 

DD  1 JAN  ^73  1473  EDITION  OF  1 NOV  6S  IS  OBSOLETE 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 


PROJECT 


GUARDIAN 


PROTOTYPE  SECURE  MULTICS 
SPECIFICATION 


Preliminary  Oraft 
January  31*  1976 


prepared  for 

Department  of  the  Air  Force 
Electronic  Systems  Oivision 
Hanscom  Air  Force  Base 
Beaford*  Massachusetts  G1731 


Contract  No.  F19623-74-C-G193 
CORL  Sequence  No.  AO 13 


Honeywell  Information  Systems*  Inc. 
Federal  Systems  Operations 
7900  Hestoark  Drive 
McLean,  Virginia  22101 


Hon  eywe 1 I 


O-aft  1-31-76 


Contents 


Introduction 

1.0  Scope 

1.1  Identification  and  Authority 

1.2  Backgrouna 

1.3  Purpose 

2.3  Applicable  Documents 

3.0  Functional  Requirements  for  a Secure  Multics 
o.l  Definition  of  Concepts  ana  Terminology 

3.2  Overview  of  System  Architecture 

3.2.1  Hardware  Configuration 
3«2»2  Interna  I /Externa I Environment 

3.2.3  The  Security  Kernel 

3«2.4  The  Secure  Front-End  Processor 
3*2.5  The  System  Security  Perimiter 

3.3  Process  Creation 

3.3.1  Logging  Into  the  System 

3.3.2  User  Authentication 

3.3.3  Process  Clearance  Assignment 

3.4  The  Multics  Storage  System 

3.4.1  Access  to  Segments 

3.4.2  Access  to  Directories 


1 


1 


I 


Honeywell  Draft  1*31-76 

Contents  (continued) 

3*5  Use  of  I/O  Devices 
3*5.1  Internal  I/O 
3*5*2  External  I/O 
3*5.3  Bulk  I/O  services 
3*6  Interprocess  Communication 

3*6.1  Block/Wakeup  Mechanism 
3*6*2  Message  Segments 
3*7  Trusted  Processes  ana  System  Functions 
3*7*1  System  Control  Process 
3.7*2  3ackup 
3*7*3  Retrieval 

3*7.4  System  Security  Administrator 
3*7.5  System  Admini str ator 
3*7.6  Maintenance  and  Repair  Processes 
3.7.7  The  I/O  Coordinator  Process 
3.8  System  Audit 

4.0  Quality  Assurance 

♦ I 

5.0  Preparation  for  Delivery 

6.0  Notes 


2 


Hot ey we  I I 


Draft  1-31-76 


Introduct ion 


Several  years  ago*  the  Air  Force  identified  a need  for  a general 
pj-pose  computer  system  which  could  securely  protect  all 
information  it  contained.  The  two  general  requi remants  were! 
access  controls  which  would  support  the  military  security  system? 
and  certification  that  the  access  controls  could  not  be  defeated 
by  a malicious  user  or  by  accidental  failure.  Honeywell  has  been 
working  with  the  Air  Force  to  develop  this  secure  system  based  on 
the  architecture  of  Honeywell's  Multics  system. 

Tne  first  task  was  to  design  the  access  controls  to  suoport  the 
military  security  system.  This  task  has  been  completed  and 
resulted  in  the  inclusion  of  the  Access  Isolation  Mechanism  in 
the  iiultics  standard  proouct. 

Tne  next  task*  certifying  the  correctness  of  the  access  controls* 
is  a much  larger  effort.  This  report  attempts  to  provide  an 
initial  description  of  a prototype  secure  Multics  system  capable 
of  meeting  some  certification  criteria.  The  description  is 
preliminary  and  is  expected  to  change  as  future  design  efforts 
prpvice  further  insight  into  the  problems  of  certification. 

Tne  modifications  described  in  this  report  for  the  development  of 
a prototype  secure  Multics  system  are  subject  to  formal  approval 
by  both  Honeywell  and  the  Air  Force  before  they  become  oinding  on 
fj-ther  development  efforts. 
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1.  SCOPE 


1.1  Identification  and  Authority 


The  authority  for  this  specification  is  contained  in 
contract  number  Fi9623-74-C-0l93.  The  soe c i f ica t i on 
corresponds  to  CQRL  sequence  numoer  AG13. 


1.2  Background 


The  problem  of  security  in  computer  systems  has  Dean  under 
study  for  several  yea^s.  The  Air  Force  has  sponsored 
several  studies  and  development  projects  aimed  at  improving 
unoerstanding  of  security  in  computer  systems,  developing  a 
sound  theoretical  basis  for  further  work,  and  demonstrating 
accomplishments  in  the  field.  Many  of  these  projects  have 
been  associated  with  the  Multics  system. 

The  overall  goal  of  these  efforts  has  oeen  to  develop  a 
certifiably  secure  computer  system  for  general  use  by  the 
military  to  meet  thei~  operational  requirements.  This 
report  is  part  of  an  effort  to  take  the  Multics  system  from 
its  present  form  to  a orototype  Multics  system  which  can  be 
used  to  demonstrate  the  feasibility  of  software 
certi f icat ion. 

The  military  faces  an  increasing  need  for  operational 
computer  systems  capable  of  processing  several  levels  of 
classified  information  at  the  same  time.  Present  systems 
are  unable  to  support  secure  multilevel  processing  due  to 
fundamental  weaknesses  in  their  basic  design,  since  security 
was  not  a concern  when  they  were  developed.  The  weakness  is 
that  current  haraware/so f t ware  systems  are  jn3ble  to 
adequately  protect  the  information  that  they  process. 

Currently,  the  military  meets  the  need  for  orocessing 
several  levels  of  information  by  one  of  two  methods.  Either 
all  security  levels  are  processed  together  at  the  level  of 
the  highest  classification  present,  or  each  level  is 
processed  by  itself.  Both  metnods  nave  been  less  than 
satisfactory.  The  problem  with  processing  all  levels 
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together  is  that  a! I users  and  all  equipment*  including 
terminals  and  communications  facilities*  must  be  cleared  to 
the  highest  classification  that  the  system  can  eve~  process. 
The  problem  with  separate  processing  is  that  a separate 
computer  system  or  a separate  period  of  time  is  required  for 
each  level  handled.  Either  method  is  costly  and 
inefficient.  Neither  method  allows  simultaneous  handling  of 
information  at  several  levels  for  users  of  several  levels  of 
c I earance. 

Multics  is  the  most  advanced  general  utility  system  as  far 
as  security  is  concerned.  Security  was  one  of  the  initial 
design  goals  of  the  Multics  system  designers  and  has  been  a 
major  concern  of  the  aesigners  and  developers  throughout  the 
history  of  the  system.  Even  with  this  concern  for  security* 
the  present  Multics  system  cannot  be  certified  secure. 
Mjltics*  however*  does  present  the  best  available  base  upon 
which  to  build  a certifiably  secure  multilevel  computer 
utility. 

Secure  communications  has  also  presented  operational 
problems  to  the  military.  A secure  on-line  system  requires 
a secure  communications  network.  While  the  techniques  of 
securing  communications  lines  and  terminals  have  been  well 
developed*  a certifiably  secure  communications  processor  is 
still  undeveloped.  A secure  Multilevel  system  must  have  a 
compatible  and  Secure  Front-End  Communications  P-ocessor  to 
be  able  to  properly  handle  multiple  levels  of  classified 
information. 

Both  economic  and  operational  cons  id er ati ons  make 
development  of  a certifiably  secure  multilevel  system 
desirable.  Recent  advances  in  computer  technology  indicate 
tnat  it  should  be  possible  to  produce  a system  that  can 
process  an  arbitrary  mix  of  classified  ana  unclassified 
information  simultaneously  on  a single  computer  system.  The 
system  should  serve  both  cleared  and  uncleared  users  and 
should  rely  on  the  computer  system's  internal 
harqware/ so f twar e controls  to  enforce  secu~ity  and 
need-to-know  requir emen ts . Of  primary  importance  is  that 
the  system  be  certifiably  secure.  That  is*  it  must  be 
possible  to  prove  that  the  system  is  complete  and  without 
flaw  in  any  of  its  securi t y-re I at ed  aspects. 


The  Air  Force  has  been  working  on  the  problem  of  oroviding  a 
certifiably  secure  multilevel  system  for  several  years.  In 
1970*  the  Air  Force  Data  Services  Center  (AFQSC)  -equested 
The  Electronic  SysTems  Division  (ESQ)  to  support  development 
of  an  open  multilevel  system  for  the  AFDSC  Honeywell  635 
systems.  The  resulting  studies  pointed  out  the  severity  of 
the  problem  and  led  to  the  formation  of  a compute1’'  security 
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technology  planning  study  D3nel.  The  panel's  reoort  (2.19) 
described  the  fundamental  proolems  and  delineated  a program 
to  aevelop  the  desired  system.  The  panel  recommended  that 
the  technical  approach  to  the  problem  be  "to  start  with  a 
statement  of  an  ideal  system*  a model*  and  to  refine  and 
move  the  statement  through  various  levels  of  design  into  the 
mechanism  that  implement  the  model  system”. 

The  basic  component  of  the  ideal  system  was  also  identified 
by  this  panel.  This  component  is  known  as  the  Reference 
Monitor*  an  abstract  mechanism  that  controls  access  of 
subjects  (active  system  elements)  to  objects  (units  of 
information)  within  the  computer  system  and  enforces  the 
rules  of  the  military  security  system  on  such  access.  Three 
requirements  were  recognized  for  a Reference  Monitor: 

a.  Complete  Mediation  - the  mechanism  mjst  mediate 
every  access  of  a subject  to  an  object. 

b.  Isolation  - the  mechanism  and  its  data  oases  must 
be  protected  from  unauthorized  alteration. 

c.  Verifiability  - the  mechanism  must  oe  small* 
simple*  and  underst andab I e so  that  it  can  be 
completely  tested  and  verified  (ce-tified)  to 
perform  its  functions  correctly. 

The  mechanism  that  imolements  the  Reference  Monitor  in  a 
particular  computer  system  has  been  termed  tne  security 
kernel.  Much  subsequent  work  has  been  devoted  to 
iaenrifying  the  characteri sties  of  a security  ke-nel  and  to 
exploring  the  technology  involved  in  producing  a security 
kernel  for  some  computer  system. 

ESO  initiated  oevelopment  of  formal  mathematical  moaels  of 
the  ideal  Reference  Monitor  in  1972*  This  work  (2«i0»  2«11» 
2.13)  resulted  in  a model  of  a secure  computer  system  as  a 
finite-state  mechanism  that  makes  explicit  transitions  from 
one  secure  state  to  another.  The  rules  of  the  model 
formally  define  the  conditions  under  which  a transition  from 
state  to  state  can  occur.  The  rules  have  been  proven  to 
allow  only  transitions  that  preserve  the  security  of 
information  in  the  system.  The  model  specifies  requirements 
for  the  operation  of  a security  kernel.  These  requirements 
were  taken  airectly  from  tne  Defense  Department  regulations 
on  handling  sensitive  information  (DoD  Directive  5200.1-R). 
With  the  availability  of  the  model*  the  p-oblem  of 
validation  is  now  reaucea  to  providing  complete  assurance 
that  a particular  security  kernel  behaves  exactly  as  the 
model  requires. 
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Work  on  the  technology  of  certification  progressed  in 
parallel  with  the  work  on  the  model.  In  i973»  Rrice  (2.21) 
identified  a methodology  for  verification  of  a kernel.  More 
detailed  developments  of  this  validation  methodology  have 
been  reported  by  MITRE  (2*1 7*  2.21).  Another  approach  has 
been  explored  which  may  be  more  suitable  to  large  software 
modules  (2*23). 

Other  activities  have  been  devoted  to  the  problem  of 
building  a security  kernel  for  a practical  system  (2*16, 
2.24).  This  work  has  demonstrated  the  soundness  of  the 
basic  concepts  and  also  pointed  out  some  of  toe  problems 
that  lie  in  the  way  of  realizing  a security  kernel  on  a 
large  system.  Tnis  work  has  been  the  basis  for  development 
of  a secure  communications  processor*  a detailed  effort 
which  is  presented  later  in  this  report. 

A major  project  in  the  development  process  is  the 
development  of  a security  kernel  for  a large  resource 
sharing  system.  The  system  chosen  for  this  effort  is 
Multics.  There  are  two  reasons  that  this  choice  was  made. 
First,  the  hardware  oase  of  the  Multics  system,  the 
Honeywell  68/8;  computer,  has  been  identified  as  oast  suited 
of  all  off-The-shelf  large  computer  systems  for  tie  support 
of  a security  kernel  (2.25).  Second,  the  Multics  system 
architecture  was  conceived  ano  developed  with  security 
requirements  specifically  in  mind. 

One  project,  now  completed,  involved  the  design  and 
production  of  a Multics  system  capable  of  sjpoorting  a 
two-level  (Secret  and  Too  Secret)  environment  for  the  Air 
Force  Data  Services  Oente”  (2«l5,  2*26).  Tnis  system 
implements  security  controls  based  on  tne  military  access 
rules,  but  it  does  not  completely  nandle  the  threat  of  a 
hostile  penetration.  From  these  efforts,  additional  insight 
was  gained  in  the  problems  of  designing  and  developing  a 
security  kernel  for  MulTics. 

Design  of  a security  kernel  for  Multics  was  sta~ted  as  a 
Joint  effort  between  personnel  from  ESD,  the  MITRE 
Corporation,  the  Massachusetts  Institute  of  Technology,  and 
Honeywell  Information  Systems.  This  design  effort  has  led 
to  a more  complete  understanding  of  the  general  problem. 
Work  is  progressing  on  formal  specifications  for  the  Multics 
security  kernel  (2,27)  and  on  simplification  and 
reorganizat ion  of  the  Multics  operating  system.  8ased  on 
these  efforts,  the  current  Multics  system  will  oe  refined 
and  critical  portions  of  the  system  will  be  re i mpl ementeo  to 
produce  a certifiable  wernel  which  will  inte-face  with  a 
certifiaole  front-end  communications  processor  with  its  own 
security  kernel.  The  resjlt  will  be  a a prototype  Multics 
system  which  may  meet  the  goal  of  Air  Force  ce-t i f icat ion. 
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The  overall  project  can  oe  described  in  terms  of  three  major 
development  activities*  development  of  a technology  to 
support  the  development  of  3 certifiable  system,  development 
of  hardware  and  software  for  a prototype  Secure  Front-End 
Processor,  ana  aevelopment  of  a certifiable  prototype 
Multics  system  with  a security  Kernel  interfacing  with  the 
Secure  Front-End  Processor. 

A new  collection  of  programming  methodologies  and  techniques 
is  developed  to  sjpport  the  major  Multics  and  SFEP 
development  activities.  Included  are*  techniques  for 
formally  specifying  software?  techniques  for  demonstrating 
the  correspondence  among  hierarchically  ordered  levels  of 
specification?  programming  languages  emphasizing  the 
generation  of  certifiable  code?  and  support  tools  aiding  the 
automation  of  certification  of  specifications  and  code,  and 
performance  measurements. 

The  Secure  Front-Ena  Processor  is  developed  using  a hardware 
architecture  designee  specifically  to  provide  a basis  for 
certification  accoraing  to  the  Air  Force  security  model. 
The  haraware  provides  segmented  addressing  and  interfaces 
directly  with  the  prototype  Multics  system.  Tne  software 
provides  a kernel -based  system  architecture  with  a 
supervisor  supporting  communications  subsystems  fo~  external 
I/O.  The  initial  version  of  the  SFEP  software  is  integrated 
with  the  Kernel-based  Multics  system  to  demonstrate 
functional  capability.  A second  SFEP  version  is  then  coded 
in  the  new  system  programming  language,  incorporates 
performance  enhancements  and  is  then  integrated  with 
Mu  I tics. 

Development  of  the  certifiable  prototype  Multics  system 
entails  the  restructuring  of  tne  present  Multics  supervisor 
to  rely  on  a formally-specified  security  Kernel  leading  to 
three  Demonstrable  prototypes.  The  first  demonstrable 
prototype  employs  a f or ma) I y- spec i f i ed  Kernel,  coded  in 
PL/I,  interfacing  with  a OATANET  66QQ  front-end  processor 
and  establishes  functional  ana  performance  measures  of  the 
design.  The  second  demonstrable  prototype  incorporates  the 
Secure  Front-End  Processor  to  demonstrate  successful 
integration  of  the  two  hardware  systems  with  their 
respective  Kernels  and  supervisors.  The  third  demonstrable 
prototype  incorporates  performance  enhancements  and  contains 
Kernels  cooea  in  the  new  system  programming  languages.  This 
last  prototype  establishes  the  feasibility  of  certifying 
code  correctness  aided  by  the  support  tools  developed  as 
part  of  the  project. 
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1*3  Purpose 


This  document  is  the  first  step  towards  the  specification  of 
a certifiaole  secure  prototype  Multics  system.  The  problems 
and  implications  of  restruc turing  the  present  Multics 
supervisor  to  rely  on  a formally-specified  security  Kernel 
are  examined.  The  mathematical  model  of  computer  security 
prepared  by  the  MITRE  Corporation  (2»lu»  2»li>  provides  the 
theoretical  criterion  for  evaluating  design  alternatives. 
The  result  is  a functional  description  of  the  user  interface 
as  modified  to  sjpport  a kernel-oaseo  system  design. 

The  system  architecture  described  here  will  provide  the 
basis  for  more  detailed  and  formal  specifications  of  the 
security  Kernel  and  revised  supervisor.  These  will  be 
prepared  during  the  course  of  developing  a prototype  secure 
Mu  I tics  system. 

The  form  of  presentation  for  this  specification  assumes  a 
good  working  Knowledge  of  the  structure  of  the  current 
Multics  system.  Readers  are  directed  to  the  Honeywell 
documents  listed  in  paragraph  2.7  for  more  information  on 
the  concepts  presented. 


1.3*1  Specific  Exclusions 


Certain  problems  of  multi-level  security  AQP  opa*ation  and 
extensions  of  basic  multi-level  security  controls  were  Known 
at  the  start  of  the  design  effort  and  were  specifically 
excluded.  Certain  system  functions  which  do  not  serve  to 
demonstrate  the  feasibility  of  the  security  kernel  concept 
have  been  specifically  excluded.  These  are  described  in  the 
following  paragraphs. 


The  Trojan  Horse  Proolem 


A computer  system  which  provides  sharing  of  user  written 
procedures  is  susceptible  to  a “Trojan  Horse  attack”  by  a 
malicious  user  (See  Section  3.1.3  for  definition.)  A 
general  solution  to  the  Trojan  Horse  problem  is  excluded 
from  the  scope  of  the  design  effort.  However,  reducing  the 
information  paths  between  users  of  different  security  levels 
is  within  the  scope  of  the  design  effort.  The  issue  of 
sabotage  from  a Trojan  Horse  is  accepted  with  a low 
expectation  of  occurrence  in  a system  used  for  general 
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purpose  computing.  Howei/er,  an  act  of  sabotage  oy  a Trojan 
Horse  could  have  considerably  more  severe  consequences  at 
certain  military  sites  SJCh  as  those  having  a command  and 
control  environment. 


l»3»i«2  High-Water  Mark 


The  design  of  having  users  start  work  at  a low-security 
level  with  automatic  or  requested  upgrade  to  a 
hi gher-securi ty  level  as  more  sensitive  data  is  needed  was 
specifically  excluaed  from  the  scope  of  this  design.  This 
is  commonly  aescribed  as  a "high-water  mark"  capaoility. 


1»3»1«3  Program  Trustworthiness 


The  ability  to  redjce  the  system  recognized  clea~ance  of  a 
user  who  may  attempt  to  access  sensitive  material,  based  on 
the  clearance  level  of  procedures  executed  in  a user’s 
process,  is  commonly  described  as  the  "trustworthiness" 
capability.  This  is  one  means  to  reduce  the  ootential 
damage  by  a Trojan  Horse  attempting  to  perform  sabotage. 
This  "trustworthiness"  capaDility  is  specifically  excluded 
from  the  scope  of  the  design  effort. 


1.2. 2. 5 Accounting,  Billing  and  Load  Control 


The  current  accounting  ana  oilling  procedures  form  a very 
large  subsystem  on  Multics.  Many  interfaces  to  the  system 
are  involved,  most  of  which  will  now  contain  mjlti-level 
security  aata.  The  restructure  of  the  system  will  change 
most  of  these  interfaces,  tnus  requiring  a large  effort  to 
make  the  accounting  and  billing  procedures  wo-k  on  a 
kernel-based  Multics  system.  No  benefit  in  the 
demonstration  of  a prototype  secure  Multics  system  will 
accrue  from  making  such  modifications  at  this  time. 
Therefore,  accounting  and  billing  functions  are  specifically 
excluded  from  this  effort. 

Also,  the  load  control  group  mechanism  is  only  needed  for  a 
heavily  used  Multics  service.  Only  a primitive  mechanism  is 
needed  to  demonstrate  the  feasibility  of  a ke-nel-based 
Mul tics  system. 
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2.  APPLICABLE  DOCUMENTS 


2*1  Air  Force/Honey we M contract  number  F19628-74-C-0 193 

This  contract  provides  the  authority  for  the  design  effort* 
The  documentation  requirements  for  the  final  report  and  the 
alioweo  deviations  from  the  format  are  specified  in  this 
contract • 


2*2  DoD  5200.1-R  Information  Security  Program  Regulation 

Describes  the  military  security  system  3nd  the 
responsibi I ities  of  personnel  who  fall  within  its 
j urisdiction. 


2*3  AFR  205-1  Information  Security  Program  (USAF) 
Implements  DoD  52CQ.1-R 


2*4  DoD  5200*28  Department  of  Defense  Directive,  Security 
Requirements  for  Automatic  Data  Processing  (ADP)  Systems 

Defines  the  security  requirements  for  processing  classified 
data  on  an  ADP  system  (See  2*5). 


2*3  DoD  5200*28-M  Manual  of  Techniques  and  Procedures  for 
Implementing,  Deactivating,  Testing,  and  Evaluating  - Secure 
Resource  Sharing  AOP  Systems* 

This  is  the  manual  which  outlines  the  details  of  the  general 
requirements  specified  in  DoD  5200.28. 


2.0  MIL-STO-483  Appendix  III 

Air  Force  suggested  documentation  format  specification  for 
the  final  report. 

This  standard  has  been  followed  for  content  and  general 
order  of  presentation.  Deviations  from  the  strict  format 
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were  authorized  by  the  contract  (Paragraph  2.1).  Section  3 
of  the  standard  has  oeen  expanded  in  this  document  to 
provide  a form  of  presentation  better  suited  to  the 
material . 


2. 7 Standard  Honeywell  Multics  documentation 

The  following  documents  are  mentioned  here  as  a source  of 
background  information  concerning  the  Standard  Multics 
sys  tem . 

Multics  Programmers*  Manual 
Introduction  (AG90) 

Reference  Guide  (AG91) 

Commands  and  Active  Functions  (AG92) 

Subroutines  (AG93) 

Subsystem  Writer*s  Guide  (AK92) 

Project  Aomini strator * s Manual  (AK5i) 

System  Administrator* s Manual  (AK50) 

PL/I  Language  Manual  (AG94) 

Multics  Virtual  Memory  (AG95) 

The  Multics  System  (A<27) 

The  order  numbers  given  above  (e.g.  AG90)  should  be 

specified  when  ordering  these  documents  from  Honeywell. 


2.3  Multics  Evaluation*  J.p.  Anderson*  ESD-TR-73-276*  Electronic 
System  Systems  Division  (AFSC)*  L.  G.  Hanscom  Field* 
Bedford*  MA,  October  1973. 


2.3  Design  and  Certification  Approach:  Secure  Communications 

Processor,  P.  S.  Tasker  and  0.  E.  Bell*  MTR-243&*  The  MITRE 
Corporation*  Bedford*  MA. 

2.10  Secure  Computer  Systems:  Mathematical  Foundations*  Q.  E. 
Bell  and  L.  J.  LaPadula*  ESD-TR-73-273*  Vol  I,  Electronic 
Systems  Division  (AFSC),  L.  G.  Hanscom  Field*  Bedford*  MA* 
November  1973. 

2.11  Secure  Computer  Systems:  A Mathematical  Model*  L.  J. 

LaPaoula  and  0.  E.  Bell,  ESD-TR-73-278*  Vol  II*  Electronic 
System  Division  (AFSC)*  L.  G.  Hanscom  Field,  Bedford*  MA, 
November  1973. 

2*12  Computer  Secure  Research  and  Development  Requi r ema n t s * S.  B« 
Lipner*  MTP-142*  The  MITRE  Corporation,  Bedford*  MA, 
February  1973. 
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2.13  Preliminary  Notes  on  the  Design  of  Secure  Military  Computer 
Systems*  R.  R.  Schell*  P • J.  Downey*  and  5.  J.  PopeK* 
MCI-73-1,  Electronic  Systems  Division  (AFSC) * L.  S.  Hanscom 
Field,  Bedford*  MA*  January  1973. 

2.14  Concept  of  Operation  for  Handling  I/O  in  a Secure  Computer 
at  the  Air  Force  Data  Services  Center  (AFDSC) * E.  L.  Burke* 
ESD-TR-74-113 » L.  G.  Hanscom  Field*  Bedford*  MA,  October 
1973. 

2.15  Design  for  Multics  Security  Enhancements,  J.  Whitmore,  A. 
Bensoussan,  P.  Green,  D.  Hunt,  A.  Kobziar,  J.  Stern* 
ESO-TR-74-176 * L.  G.  Hanscom  Field*  Bedford,  MA  1973 

2.16  The  Design  ana  Specification  of  a Security  Kernel  for  the 
PDP-11/45,  W.  L.  Schiller,  ESD-TR-75-69,  L.  G.  Hanscom 
Field,  Bedford*  MA,  May  1975 

2.17  A Software  Validation  Technique  for  Cer t i f icat i on J The 
Methodology,  D.  E.  Be  I I and  E.  L.  Burke,  ESD-T R-75-54 , 
Electronic  Systems  Division  (AFSC),  L.  G.  Hanscom  Field, 
Bedfora,  MA.,  April  1975 

2.18  Primitive  Models  for  Computer  Security*  K.  G.  Walter*  W.  F. 
Ogden*  W.  C.  Rounds*  et  al  Department  of  Computing  and 
Information  Sciences,  Case  Western  Reserve  University, 
Cleveland*  Ohio,  ESD-TR-74-H7 » Electronic  Systems  Oivision 
(AFSC),  L.G.  Hanscom  Field*  Bedfora*  MA.,  January  1974 

2*19  Computer  Security  Technology  Planning  Study,  J.  p.  Anderson, 
ESD-TR-73-51,  Vol  II,  Electronic  Systems  Oivision  (AFSC)* 
L.G.  Hanscom  Field,  Bedford*  MA.,  October  1972 

2.21  Computer  Security  Development  Summary*  ESO  2073,  Electronic 
Systems  Oivision,  L.G.  Hanscom  Field,  Bedford,  MA.,  Oecember 
1973 

2.21  Implications  of  a Virtual  Memory  Mechanism  for  Implementing 
Protection  in  a Family  of  Operating  Systems,  W.  R.  Price, 
PhD  Thesis,  Carnegi e-Me 1 1 on  University,  June,  1973 

2.22  Synthesis  of  a Software  Security  System,  E.  L.  Burke, 

MTP-154,  The  MITRE  Corporation,  Bedford,  MA. 

2*23  On  Attaining  Reliable  Software  for  a Secure  Operating 

System,  L.  Robinson,  P.  G.  Neumann,  K.  N.  Levitt,  A.  Saxena, 

1975  International  Conference  on  Reliable  Software,  Los 
Angeles,  Ca.,  April  1975 

2*24  Design  of  a Security  Kernel  for  the  POP-11/45,  W.  L. 

Schiller,  The  MITRE  Corporation,  Bedford,  MA.,  December  1973 
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2.25  Architectures  for  Secure  Computing  Systems.  L.  Smith, 
ESD-TR-75-51,  The  MITRE  Corporation.  Bedford.  MA,.  June  1974 

2.26  Access  Isolation  Mechanism  Pre-Release  Documentation. 
Honeywell  Information  Systems.  Inc..  McLean.  Va..  August 
1975 

2*2 7 The  Top  Level  Specification  of  a Multics  Security  Kernel.  W. 
L.  Schiller,  K.  J.  Biba,  E.  L.  Burke,  Working  Paper 
WP-20377,  The  MITRE  Corporation,  Bedford,  Ma.,  Augjst  1975 

2.28  Initial  Structured  Specifications  for  an  Uncomoromi sab  I e 
Computer  Security  System,  K.  G.  Walter,  W.  F.  Ogden,  et  al 
Case-Western  Reserve  University,  Cleveland,  Ohio,  July  1975 
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3.0  Functional  Requirements  for  a Secure  Multics 


A secure  computer  system  is  one  which  can  successfully 
protect  all  data  entrusted  to  it  from  unauthorized 
cisclosure.  This  is  the  basic  definition  of  system  security 
or  more  specifically  system  software  security  which  guides 
the  Guardian  project.  Issues  of  physical  security  which  can 
aeny  service  to  authorizea  users  are  specifically  ignored 
here  <e.g.»  fire*  flood*  etc.).  The  major  concern  is  to 
counter  all  security  threats  which  would  allow  someone  to 
steal  information  (or  data)  from  the  computer  system.  The 
security  threats  of  general  interest  fall  into  three  logical 
areas*  malicious  persons  external  to  the  system*  authorized 
users  of  the  system  and  collusion  between  authorized  users. 

Tne  threats  from  malicious  persons  external  to  the  system 
are  not  particularly  interesting  to  the  system  software 
designer.  Tnese  threats  include!  tapping  communication 
lines*  stealing  listings*  tapes*  terminal  outpjt  or  other 
data  generated  by  the  system*  stealing  passwords  of 
autnorized  users!  monitoring  e I ac froraagnet ic  emanations  from 
the  hardware;  or  unauthorized  actions  by  operations  or 
administrative  personnel.  tacn  of  the  threats  mentioned  can 
only  oe  countered  by  physical  or  procedural  security 
measures  external  to  the  computer  system.  The  only  external 
threats  of  interest  to  The  system  software  designer  are 
illegal  entry  attempts  (login)  ana  ooerationsJ  errors* 
These  are  solved  by  tne  use  of  passwords  for  user 
authentication  ana  by  providing  unambiguous  instructions 
and/or  messages  to  operations  personnel. 

Tne  threats  from  collusion  oetween  authorized  use^s  is  also 
uninteresting*  The  Multics  Access  Isolation  Mecnanlsm  makes 
it  extremely  difficult  for  two  users  of  different  security 
clearances  to  compromise  data  while  it  remains  resident  in 
Multics*  even  though  tne  current  system  is  not  certified 
secure.  Therefore*  two  or  more  users  in  collusion  to  steal 
data  wifi  find  It  easier  to  pass  the  data  external  to  the 
system!  an  inforraaTion  channel  which  is  beyond  The  control 
of  tne  system  Designer* 

The  remaining  security  threats  come  from  persons  authorized 
to  use  the  system.  This  is  the  area  of  particular  Interest 
in  this  development  effort.  The  less  severe  internal 
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threats  of  browsing  by  a curious  user  and  accidental 
granting  of  access  have  oeen  addressed  by  the  imp  I ementat in 
of  the  Access  Isolation  Mechanism.  The  insidious  threats  of 
a Trojan  Horse  program  or  system  penetration  remain  to  be 
solved. 

Within  the  Multics  architecture*  a general  solution  to  the 
threat  of  a Trojan  Horse  has  not  been  found.  However*  for  a 
Trojan  Horse  program  to  be  able  to  compromise  data*  it  must 
be  able  to  communicate  between  security  levels.  Therefore* 
one  requirement  of  this  effort  is  to  eliminate  a I I 
communication  paths  which  would  allow  a program  to  read  data 
of  one  security  level  and  write  it  where  it  could  be  read 
from  a lower  security  level. 

A user  who  can  penetrate  the  operating  system  may  pa  able  to 
invalidate  all  the  access  control  mechanisms.  A penetration 
can  occur  from  incorrect  implementation  of  the  various 
protection  mechanisms  or  from  a malicious  programmer 
inserting  special  code  sequences  to  provide  a "trap  door" 
into  the  operating  system.  Therefore*  another  requirement 
of  this  effort  is  to  verify  tne  correct  implementation  of 
the  Multics  operating  system  and  to  verify  that  no  trap 
ooors  exist. 

The  Multics  protection  mechanisms  are  implemented  within  the 
most  privileged  protection  ring*  ring  0.  Unf o-tunate I y » 
there  are  a large  number  of  programs  in  ring  0 which  are 
very  complex.  The  interactions  between  these  programs  are 
also  complex  and  often  subtle  or  obscure.  In  addition, 
there  are  no  mechanisms  to  protect  programs  and  data  within 
ring  C from  errors  in  other  programs  in  this  ring. 
Therefore*  any  attempt  to  verify  the  correctness  of  the 
current  Multics  supervisor  as  it  exists  is  doomed  to  failure 
from  the  sta~t. 

The  approach  to  meeting  the  requirements  is  to  restructure 
the  current  Multics  operating  system  to  isolate  the 
primitive  mechanisms  which  implement  the  security  access 
controls.  This  will  form  the  reference  monitor  or  security 
Kernel  of  Multics.  The  mathematical  model  of  computer 
security  (2.10*  2»ll)  is  the  criterion  used  in  defining  the 
interface  between  the  kernel  and  other  parts  of  the  system. 
Good  engineering  practice  requires  that  the  current 
operating  system  be  molded  into  the  new  structure  rather 
than  attempting  a comolete  top  down  redesign.  It  is 
expected  that  several  iterations  between  top  down 
specification  for  correctness  proofs  and  bottom  up  design 
for  engineering  feasibility  will  be  needed. 
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The  following  paragraphs  within  section  3 of 
specification  form  the  initial  description  of 
restructured  Multics  system  based  on  bottom  up  design. 


this 

the 
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3.1  Definition  of  Concepts  and  Terminology 


3.1*1  Haroware/Sof tware  Interface 

The  central  processing  unit  used  is  the  Honeywell  series  60 
level  &0/8y . The  operating  system  is  Hu  I tics  t with  sucn 
modifications  and  extensions  as  result  from  this  design 
effort  and  the  system  programming  t ask  that  will  follow. 

A full  description  of  the  Honeywell  6880  hardware  and  the 
Multics  software  is  beyond  the  scope  of  this  document.  The 
interested  reader  is  referred  to  the  publications  listed  in 
Section  2.7  for  such  detailed  descriptions. 


3.L.2  User  Interface 

The  user  interface  is  the  appearance  the  system  presents  to 
the  user.  To  the  greatest  degree  possible*  this  aopearance 
will  remain  the  same  as  current  Hultics. 

Functions  available  to  the  user  will  be  identical  to  current 
Multics  where  feasible*  and  equivalent  in  most  othe^  cases. 


3.1*3  General  Definitions 


access 


The  ability  and  the  means  to  approach,  communicate  with 
(input  to  or  receive  output  from),  or  otherwise  mawe  use  of 
any  material  or  component  in  an  ADP  System. 

In  the  military  security  system,  a person  may  oe  granted 
access  to  an  object  only  if  his  clearance  level  is  greater 
than  or  equal  to  the  classification  level  of  the  object? 
his  clearance  category  set  contains  all  categories  in  the 
category  set  of  the  object;  ana  he  has  the  prooer  "need  to 
Know"  In  reference  to  the  object. 
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A33  (Automatic  Data  Processing) 

An  assembly  of  computer  equipment*  facilities*  personnel* 
software  ana  procedures  configureo  for  the  ouroose  of 
classifying,  sorting*  calculating*  computing*  summarizing* 
storing,  and  retrieving  data  and  information  with  a minimum 
of  human  intervention. 


anonymous  user 

An  anonymous  user  is  an  unregistered  user  of  the  Multics 
system  whose  personid  (see  below)  is  “anonymous";  in  other 
words*  his  personid  is  unknown  to  the  system.  An  anonymous 
user  may  or  may  not  oe  required  to  furnish  a password  in 
order  to  gain  access  to  the  system. 


branch 

A branch  is  a component  of  a directory  which  describes  an 
immediately  inferior  segment  or  directory. 


breach 

The  successful  and  repeatable  defeat  of  security  controls 
with  or  without  an  arrest  wnich*  if  carried  to  consummation, 
could  result  in  a penetration  of  the  system.  Examples  of 
breaches  are! 

Operation  of  user  code  in  master  mode? 

Unauthorized  acquisition  of  userid  and  password;  and 

Accessing  a file  without  using  prescribed  operating  system 
mechanisms . 


category  set  (also  see  access) 

In  reference  to  a person,  a category  set  refers  to  the  set 
of  compartments  a person  is  eligible  to  access.  (The 
maximum  number  of  compartments  within  a single  system  is 
limited  to  sixteen.)  A compartment  in  this  context  is  an 
orthogonal  subdivision  of  the  classification  levels.  A 
compartment  is  like  a formal  need  to  know  authorization  to 
information  of  a certain  topic  without  consideration  of 
classification  level. 

In  reference  to  aocuments*  files  or  other  objects*  a 
category  set  refers  to  the  possible  information  soirees  used 
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to  create  the  object.  Thus  a category  set  with  several 
categories*  or  compartments*  would  indicate  that  the  object 
should  be  hanalea  with  the  extra  caution  accorded  to  objects 
which  would  intersect  the  sensitive  areas  of  each  of  the 
categories  in  the  set. 


classification  (also  see  access  and  security  level) 

One  of  an  ordered  set  of  levels  which  describes  the 
sensitivity  of  the  information  to  which  it  refers.  (The 
maximum  number  of  levels  within  a single  system  is  limited 
to  seven.)  Only  information*  documents*  data,  equioment  or 
other  objects  have  classification  levels.  Persons  need  the 
correct  clearance  to  access  information  at  any  level  higher 
than  Unclassified. 

When  compartmented  security  is  used*  a classification 
includes  both  the  level  and  the  category  set  associated  with 
an  object. 


clearance  (also  see  access  ana  security  level) 

The  eligibility  of  a person  (or  process)  to  access 
information  of  a certain  classification  level  (or  lower). 
For  example,  a person  with  a Secret  clearance  is  eligible  to 
access  information  with  classification  levels  Unclassified 


to  Secret,  but 

information. 

may  not 

have  access 

to  Too 

Secret 

When  compartmented 

secur 1 1 y 

is  used,  a 

c 1 earance 

also 

includes  the  categories  a parson  is  eligible  to  access. 

In  addition  to  the  eligibility  afforded  a person  by  his 
clearance,  he  must  also  nave  the  need  to  Know  the  classified 
information  before  he  is  given  access. 


daemon  (SysDaemon) 

Certain  Multics  processes  are  dedicated  to  performing 
supervisory  functions*  such  as  handling  I/O  requests  and 
backing  up  the  storage  system.  These  processes  are  called 
daemon  processes  and  run  with  the  SysDaemon  projectid. 


dl  -ectory 

A directory  is  a segment  in  the  Multics  storage  system 
hierarchy  maintained  oy  the  supervisor  whicn  contains 
information  about  immediately  inferior  segments.  A 
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directory  contains  a list  of  branches  analogous  to  a table 
of  contents. 


fixed  level  property 

In  order  that  no  breach  of  security  occur  within  the 
computer  system  environment*  it  is  sufficient  that  no 
process  be  permitted  to  read  information  classified  above 
its  clearance*  nor  be  permitted  to  write  information 
classified  oelow  its  clearance.  This  principle  is  Known  3s 
the  fixed  level  property.  (It  has  also  been  called  the 
"♦-property"  in  some  of  the  referenced  literature) 


initializer  process  (system  control  process*  answering  service) 

The  initializer  process  is  a special  process  which  performs 
certain  system-controlling  functions.  In  particular,  it 
initializes  the  Mulncs  environment*  monitors  and  allocates 
terminals,  creates  all  other  processes*  and  performs 
accounting  functions. 


interprocess  communication  (ipc) 

Interprocess  communication  is  a facility  which  allows  one 
process  to  communicate  with  another  In  a controlled  manner. 
Both  the  sending  and  receiving  processes  must  adhere  to  a 
specifiea  protocol. 


Mjlti-Level  Security  Mode 

A mode  of  operating  under  an  operating  system  (supervisor  or 
executive  program)  which  provides  a capability  permitting 
various  levels  ana  categories  or  compartments  of  material  to 
oe  concurrently  stored  and  processed  in  an  AOP  System.  In  a 
remotely  accessed  resource-sharing  system*  tne  material  can 
be  selectively  accessed  and  manipulated  from  terminals  by 
personnel  having  different  security  clearances  and  access 
approvals.  This  mode  of  operation  can  accommodate  the 
concurrent  processing  ana  storage  of  (a)  two  or  more  levels 
of  classified  data,  or  (o)  one  or  more  levels  of  classified 
data  with  unclassified  data  depending  upon  the  constraints 
placed  on  the  systems  by  the  Designated  Approving  Authority. 
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Operating  System  (O/S) 

An  Integrated  collection  of  service  routines  for  supervising 
the  sequencing  ana  process  ing  of  programs  by  a computer* 
Operating  systems  control  The  allocation  of  resources  to 
users  and  their  programs  end  play  a central  role  In  assuring 
the  secure  operation  of  a computer  system*  Operating 
systems  may  perform  debugging*  Input-outout*  accounting* 
resource  allocation*  compilation*  storage  assignment  tasks* 
and  other  system  related  functions  (Synonymous  with  Monitor* 
Executive*  Control  Program,  and  Supervisor)* 


pe-sonid 

The  registered  name  of  someone  who  is  authorized  to  use  the 
system.  It  is  usually  constructeo  from  the  last  name 
(surname)  of  the  person. 


p- 3 cess 

A process  Is  the  active  agent  of  the  user  on  Multics  and  (in 
the  security  system)  nas  a clearance  which  may  not  exceed 
the  user's  clearance.  The  lifetime  of  a process  normally 
corresponds  to  a user's  terminal  session  and  is  described 
internally  by  an  address  space  and  a point  of  execution. 
Qoth  the  address  space  and  the  execution  point  are  dynamic 
over  the  life  of  the  process. 


p~o  J act i d 

The  registered  name  of  a project  which  has  an  account  on  the 
system . 


Remotely  Accessed  Resource-Sharing  Computer  System 

A computer  system  which  includes  one  or  more  central 
processing  units*  peripheral  devices*  remote  terminals,  and 
communications  equipment  or  interconnection  links*  which 
allocates  its  resources  to  one  or  more  users*  and  which  can 
be  entered  from  terminals  located  outside  the  central 
computer  facility. 
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security  level  (see  also  Clearance  and  Classification) 

This  term  is  used  frequently  as  an  abbreviation  for  the 
I evel /category  combination  which  describes  a clearance  or  a 
classification.  Thus  the  “level"  of  a process  is  the 
clearance  of  the  process  and  the  “level”  of  a segment  is  the 
classification  of  the  segment. 


segment 

A segment  is  a logical  jnit  of  storage  on  Mjltics.  It 
roughly  corresponds  to  a file  stored  on  a disk  pack  and 
accessible  to  a user.  The  segment  is  the  smallest  element 
of  supervisor  access  control  in  the  Multics  storage  system. 


T~ a J an  Horse 

A Trojan  Horse  is  a procedure  which  provides  a potentially 
useful  function  to  attract  use  by  a person  having  access 
privileges  not  possessed  by  the  author  of  the  procedure. 
The  Trojan  Horse  program  detects  such  use  and  performs 
unauthorized  or  unwanted  functions  which  would  allow  the 
author  of  the  procedure  to  obtain  information  to  which  he 
ai a not  otherwise  have  access  or  to  perform  acts  of  sabotage 
which  wou I a not  otherwise  be  possible. 


user 


An  instance  of  a person  logged  into  the  system  on  a project. 
A user  is  identified  by  a userid. 


user i d 

A table  entry  which  would  describe  a user  (e.g.  an  access 
control  list  entry).  A userid  consists  of 
“personid.pro J ectid.tag,"  wnere  tag  is  normally  ”a"  for  an 
interactive  user,  “m”  for  an  absentee  user,  and  "z”  for 
certain  system  daemons.  The  userid  is  also  called  the 
"principal  Identifier"  or  “group.. id"  of  the  user. 


3.1.4  Security  Access  Rules  - Tne  Model 

Access  control  is  generally  described  as  a subject 
attempting  to  access  an  object  through  an  intervening 
reference  monitor.  The  reference  monitor  cnecks,  each  and 
every  time  a subject  attempts  to  access  an  object,  to  see  if 
the  subject  has  the  proper  aut horizat ion  to  Perform  the 
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desired  operation  (e.g.  read,  write*  execute*  append* 
modify,  Delete)*  In  Mjltics*  a process  is  the  only  subject 
whicn  can  make  a reference  to  any  object*  The  set  of 
objects  are  segments*  directories*  branches,  1/3  devices* 
message  segments,  message  segment  messages  and  interprocess 
communication  messages.  Each  object  has  a classification 
level  and  category  set  associated  with  it  (i.e.,  a security 
level*) 

In  hultics,  the  reference  monitor  which  validates  each 
reference  to  an  object  is  the  "ring  O'*  supervisor  in 
conjunction  with  processor  hardware  protection  mechanisms. 
Within  the  protection  ring  scheme  supported  by  tne  Honeywell 
68/80  processor*  ring  0 is  the  most  privileged  and  most 
protected  ring  of  operation.  All  access  control  decisions 
are  made  within  ring  fl . Each  time  a process  attempts  to 
gain  access  to  an  object,  the  clearance  of  the  process  is 
compared  with  the  classification  of  the  object  and  access  is 
either  granted  or  denied  in  accordance  with  rules  designed 
to  emulate  the  military  security  system.  In  addition  to 
classification,  certain  objects  sucn  as  segments  and 
directories  have  an  associated  access  control  list  which 
specifies  persons  having  need  to  know  authorization  as  in 
the  military  security  system. 

When  the  security  level  of  two  objects  is  compared,  four 
relationships  are  possible! 

less  than 

equal 

greater  than 
isolated 

The  security  level  of  object  1 is  considered  "less  than'*  the 
security  level  of  object  2 if! 

1»  The  level  of  object  1 is  numerically  less  than  or 
equal  to  the  level  of  object  25  and 

2.  The  category  set  of  object  i is  a subset  of  the 
category  set  of  object  2?  and 

3*  The  security  level  of  object  l is  not  equal  to  the 
security  level  of  object  2. 

The  security  levels  of  two  objects  are  considered  "equal" 
if : 
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1*  The  levels  are  numerically  equal?  and 

2.  The  category  sets  are  identical. 

The  security  level  of  object  i is  considered  "greater  than" 
the  security  level  of  object  2 if: 

1.  The  level  of  object  i is  numerically  greater  than 
or  equal  to  the  level  of  object  2i  and 

2.  The  category  set  of  object  2 is  a sjbset  of  the 
category  set  of  object  l*  and 

3.  The  security  level  of  object  1 is  not  eqjal  to  the 
security  level  of  object  2. 

The  security  levels  of  two  objects  are  considered  "isolated" 
if  the  category  sets  are  isolated. 

The  "minimum"  of  several  security  levels  is  defined  ass 

1.  The  numerical  minimum  of  the  levels?  and 

2.  The  intersection  of  tne  category  sets. 

In  oraer  for  a person  to  access  information*  the  military 
security  system  requires  that  the  clearance  of  the  person  be 
greater  than  or  equal  to  the  classification  of  the 
information.  A sufficient  condition  for  satisfying  this 
requirement  witnin  the  computer  system  environment  is  the 
enforcement  of  tne  following  two  rules: 

1.  A process  having  clearance  q may  not  "read  jo*"  i.e. 
read  an  object  having  a classification  greater  than  q. 

2.  A process  naving  clearance  n may  not  "write  down*"  i.e. 
write  an  object  having  a c I assi f icati on  less  than  n. 

With  these  two  rules  enforced*  it  is  impossible  for  any 
process  to  extract  information  from  an  object  of  higher 
classification  or  to  transfer  information  from  an  object  of 
higher  classification  to  an  object  of  lower  classification. 
Hence*  no  compromise  of  classified  information  can  occur. 
This  principle  is  known  as  the  "fixed  level  property." 

It  is  important  to  recognize  that  the  rules  desc~ioed  above 
represent  a sufficient*  out  not  a necessary  condition  for 
achieving  security.  Although  the  fixed  level  property 
restrictions  will  be  strictly  enforced  for  all  user 
processes*  they  will*  in  certain  circumstances*  oe  applied 
i nt erpr et i vel y for  trusted  system  processes.  In  no 
circumstances*  however*  will  security  be  violated*  because 
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trusted  system  processes  ag.il  operate  correctly. 
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3*2  Overview  of  System  Architecture 


3*2«i  Hardware  Configuration 

Information  transmitted  oetween  hardware  modules  must  be 
carefully  controlled  by  the  system  and  no  user  should  be 
able  to  directly  affect  the  action  of  an  active  module 
(except  for  the  CPU). 


3.2.2  Interna  I /Externa  I Environment 

The  system  can  be  logically  divided  into  two  env i ~ onments : 
internal  and  external.  The  internal  environment  is  totally 
controlled  by  the  system.  This  includes:  orocessors* 
memory,  disk  drives*  I/O  multiplexers*  bu I * store* 
communication  processors*  and  tape  drives  used  for  system 
functions. 

The  external  environment  can  be  directly  influenced  by  the 
actions  of  a process.  This  environment  includes: 
terminals*  line  printers*  card  readers*  card  punches* 
non-system  taoe  drives*  and  other  aevices  in  the  I/O  class 
not  used  for  system  functions. 


3.2*3  The  Security  Kernel 


(To  be  determined  at  a later  date.) 


3.2.4  The  Secure  Front  End  Processor 


(To  be  aeterminad  at  a later  date.) 


3*2*5  The  System  Security  Perimiter 
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(To  be  determined  at  a later  date.) 
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3*3  Process  Creation 


The  Multics  access  control  mechanism  depends  on  several 
important  factors*  First  ana  foremost  is  the  notion  of  an 
unforgeable  "user  name"  and  clearance  which  identifies  the 
access  rights  of  a Multics  process?  the  entity  which 
performs  all  tasKs  on  behalf  of  the  human  user.  A Multics 
"user  name"  consists  of  tnree  components!  Person*  Project* 
ana  Tag.  The  Person  component  uniquely  identifies  a 
registered  user  of  Multics.  The  Project  component 
iaentifies  a registered  project*  and  Tag  is  presently 
derived  from  the  type  of  process  (i.e.  interactive* 
absentee*  or  consoleless  daemon). 


3.3*1  Logging  Into  the  System 

All  interactive  users  of  Multics  must  login  from  a terminal. 
Terminal  identification  plays  an  important  role  in  determing 
the  classification  of  data  which  can  be  accessed  by  a 
process.  Clearly  we  cannot  allow  a user  to  extract 
sensitive  data  while  using  a dial  up  terminal  connection 
from  a phone  booth  in  a puolic  area*  even  though  he  is 
properly  clearea.  Terminals  are  associated  with  the 
security  level  of  the  controlled  area  in  which  they  are 
locatea.  Each  terminal  (or  multiplex  group  as  in  a network) 
has  a security  level  whicn  describes  the  highest 
classification  of  data  wnicn  can  oe  processed  from  the 
terminal.  Physical  control  of  access  to  the  terminal  area 
ensures  that  all  persons  who  could  see  the  terminal  output 
are  cleared  to  at  least  the  security  level  of  the  terminal. 
This  will  be  discussea  fjrther  in  Section  3.3.3. 

There  are  two  classes  of  interactive  users  on  Multics! 
registered  users  and  anonymous  users. 

A registered  user  is  known  to  the  system  by  ois  name 
(personid)  and  is  associated  with  one  or  more  projects 
(projectio)  for  accounting  ana  resource  control  purposes. 
Each  personid  has  a password  to  authenticate  his  identity. 

To  log  into  Multics*  a registered  user  must  give  his 
personid  ana  projectid  to  the  system  control  process. 
Control  arguments  to  the  login  command  allow  the  user  to 
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specify  a desired  security  level  for  his  process*  as  well  as 
other  attributes.  The  password  will  be  requested 
immediately  following  the  login  command. 


Anonymous  users  should  not  normally  be  permitted  on  the 
system  since  password  authentication  is  not  always  required 
for  them.  Where  passwords  are  required  for  anonymous  users* 
these  passwords  are  controlled  by  project  admi ni strators 
rather  than  the  system  administrator  (SA)  or  the  system 
security  admi n i stra tor  (33A).  If,  at  any  time*  anonymous 
users  are  permitted  on  the  system,  they  a~e  always  be 
assigned  system_low  processes. 


3.3*2  User  Authentication 

In  order  for  Multics  to  successfully  enfo-ce  access 
controls*  it  must  be  possible  to  uniquely  and  positively 
identify  each  user  at  login.  Tnis  is  presently  accomplished 
by  assigning  each  registered  person  his  own  password*  and  at 
each  login*  requesting  his  password  for  verification 
purposes.  If  the  password  stored  by  Multics  matches  the 
password  given  by  the  user*  Multics  assumes  the  user  is 
valid*  and  creates  a process  with  the  "user  name"  (userid) 
of  the  user.  If,  after  giving  the  user  several  chances  (to 

allow  for  typing  mistakes),  a correct  password  has  not  been 

received*  Multics  refuses  the  login. 

Clearly*  the  password  is  a vital  part  of  the  access  control 
mechanism,  and  as  such,  must  be  carefully  protected  by  both 
the  user  and  the  system.  If  a person  could  guess  (by 

whatever  means)  another  user’s  password,  that  oe-son  would 

himself  be  ao I e to  log  in  as  the  other  user.  A season  who 
learns  anotner  person’s  password  will  not  oe  ao l a to  log  in 
with  the  same  clearance  as  the  owner  of  the  password  unless 
he*  himself*  has  an  equal  or  higher  clearance  wnlch  affords 
him  access  to  a terminal  of  equal  or  higher  classification. 
Therefore*  password  compromise  can*  at  worst*  result  in 
sabotage  or  need  to  know  violations. 

An  attempted  login  may  be  rejected  for  tha  following 
reasons  I 

1.  illegal  login  word 

2.  incorrect  personid  or  projectid 

3.  incorrect  password 
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4.  incorrect  security  level 

5.  unrecognized  login  option 

These  rejected  login  attempts  are  recorded  tor  audit 
purposes.  In  addition*  if  a user  attempts  to  use  3 terminal 
with  a maximum  clearance  greater  than  the  personid 
clearance*  a message  is  sent  to  the  operator,  since  this 
will  indicate  a breach  of  physical  security. 


3*3.3  Process  Clearance  Assignment 

When  a process  is  created  for  a user,  a clearance  is 
established  for  the  process.  This  clearance  is  not 
changeable  for  the  life  of  the  process.  It  is  the  process 
clearance  which  is  used  to  determine  a user’s  authorization 
to  access  classified  information  in  the  system. 

The  data  associated  with  a Dersonid  (the  system  unique 
identification  for  the  person)  contains  the  clearance  of  the 
Person.  Similar  clearance  data  is  associated  with  each 
projectid.  In  addition*  the  data  which  desc~ioes  the 
limitations  of  a person  on  a given  project  contains 
clearance  aata. 

The  clearance  to  be  assigned  to  a process  is  determined  as 
f o I lows! 

1.  No  process  will  be  created  for  a given  userid.  i.e.  a 

given  person  on  a given  Droject*  wito  a higher 

clearance  than  the  minimum  of  the  person’s  clearance* 
the  project’s  clearance,  and  the  person’s  clearance 
within  the  project. 

2.  No  user  should  be  ao I e to  create  a process  with  a 
higher  clearance  than  the  maximum  clea-ance  of  his 
terminal . 

3.  A user  may  request  a process  with  a lower  clearance 
than  the  minimum  of  his  userid  and  terminal  clearances. 

4.  A user  is  able  to  specify  a default  login  clearance  (no 
higher  than  his  personid  clearance). 

Only  the  SSA  is  able  to  assign  clearances  for  a personid  or 
a projectid.  If  the  SSA  lowers  the  clearance  of  a personid* 
the  user’s  process  is  forceably  terminated  if  the  user  has 
an  active  process  with  a clearance  greate~  than  the 
downgraded  clearance  of  the  personid. 
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The  Channel  Definition  Table  (COT)  is  used  by  the  system 
control  process  to  check  the  maximum  clearance  of  the 
terminal  being  used  by  a person  attempting  to  log  in. 
Normally  terminals  will  oe  "hard  wired"  to  the  system* 
thereby  allowing  each  terminal  to  be  uniquely  identified  by 
an  associated  channel  number.  In  the  general  case,  there 
may  be  crypto-dia I -up  terminals.  However,  in  that  case,  the 
crypto  units  will  provide  the  unique  terminal 
identification.  As  an  extra  check,  the  answerback  code 
received  from  a terminal  is  compared  against  its 
"registered"  answerback  code.  This  answerback  test  is 
useful  in  detecting  mistakes,  as  well  as  malicious 
tampering,  involving  communications  lines  and  terminals. 

When  a process  is  created,  there  are  two  secjrity  levels 
assigned  to  it:  the  current  authorization  and  the 
max_authorization.  The  current  authorization  is  the 
security  level  of  the  process  that  is  used  to  control  access 
to  stored  information.  The  max_author izat ion  is  the  highest 
authorization  that  can  be  assigned  to  the  process  userid. 

The  raax_aut hor i zat i on  is  calculated  as  the  minimum  of  the 
clearances  for  tne  persomd,  the  projectid,  and  the 
person-pro J ect  combination. 

The  current  authori zat i on  is  calculated  as  the  minimum  of 
the  max_authori zat ion,  the  security  level  of  the  terminal 
and  the  requested  security  level  (from  the  login  ootion  or 
default  security  level.) 

Each  user  is  tola  his  process  clearance  at  the  oeginning  of 
the  process.  In  this  way,  the  user  is  made  explicitly  aware 
of  his  level  of  operation.  Hence,  mistakes  such  as  placing 
Top  Secret  information  in  a Secret  file  are  unlikely  to 
occur . 

Aosentee  processes  are  created  at  the  level  of  the 
requesting  process.  A user  is  not  able  to  create  an 
absentee  process  with  a security  level  which  is  lower  than 
that  of  his  current  process,  since  the  passing  of  arguments 
to  the  absentee  process  would  constitute  a write-down 
operation.  The  apility  for  a user  to  enter  an  absentee 
request  of  a higher  security  level  than  his  process 
clearance  is  one  way  for  a Trojan  Horse  to  gain  control  of  a 
user's  access  permissions.  If  this  happens,  a need  to  know 
violation  or  sabotage  can  occur.  Therefore,  absentee 
processes  are  restricted  to  the  security  level  of  the 
requesting  process. 

A new_proc  option  allows  a user  to  up grade/downgr ade  his 
security  level.  When  no  option  is  specified,  the  default 
security  level  for  the  new  process  will  be  that  of  the 
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current  process*  (The  same  will  be  true  fo~  abnormal 
termination  of  a process) • 


3*3*4  Potential  Security  Prob I ams 

By  providing  a means  for  a user  to  change  his  secu-ity  level 
throjgh  program  control  (new_proc  -with  level  ootion),  a 
Trojan  Horse  could  set  itself  up  as  the  program  to  be  called 
when  a user  attempts  to  change  to  a new  security  level.  An 
elaborate  Trojan  Horse  could  totally  simulate  system  action 
for  new_proc  to  fool  the  user  into  thinking  he  is  operating 
at  a higher  level.  Now  if  the  user  attempts  to  input 
classified  data*  the  Trojan  Horse  could*  by  simulating  the 
entire  user  interface*  cause  tne  user  to  put  the  classified 
data  into  a segment  with  a lower  classification.  This 
problem  can  be  solved  by  only  allowing  a user  to  "'lew.proc" 
to  tne  same  or  lower  security  level. 

In  a similar  manner,  a user  may  write  his  own  "logout  -hold" 
command  to  fool  the  next  user  of  the  terminal  into  thinking 
he  is  talking  to  the  system  instead  of  the  previous  user’s 
process.  This  could  allow  a malicious  user  to  capture  the 
password  of  another  user,  tnus  permitting  sabotage  and  need 
to  know  violations.  Also,  the  user  environment  simulation 
described  above  could  be  used  here.  The  solution  to  this 
problem  is  to  require  the  terminal  to  be  powered  off  by  each 
user  before  attempting  to  login.  (This  can  be  handled 
several  ways.  The  choice  is  up  to  the  site  manager,) 

Solutions  exist  to  all  of  the  above  potential  problems. 
However*  given  the  low  expectation  of  occurrence  of  these 
problems*  the  required  sacrifices  in  user  convenience  were 
felt  to  be  unwarranted. 
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3.'+  The  Multics  Storage  System 


The  individual  user  is  aole  to  specify  which  users  should 
have  "need  to  Know”  for  a given  segment  or  directory  by  use 
of  the  Access  Control  List.  The  mode  of  access  (e.g.  read, 
write)  allowed  to  a process  by  the  current  Multics  Access 
Control  List  is  further  restricted  to  ensure  compliance  with 
the  fixed  level  property  rules.  In  other  wordst  the  fixed 
level  property  rule  taKes  precedence  over  the  Access  Control 
List . 


3.  + .1  Access  to  Segments 


(To  be  determined  at  a later  date.) 


3.4.2  Access  to  Directories 


(To  be  aetarmined  at  a later  date.) 
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3.5  Use  of  I/O  Devices 


(To  be  determined  at  a 


3.5.1  Internal  I/O 

(To  be  determined  at 

3*5.2  Externa!  I/O 

(To  be  determined  at 

3*5.3  Bulk  I/O  Services 


(To  be  determined  at 


later  date.) 


a later  date.  ) 


a later  date.) 


a I a + er  date.) 
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3.6  Interprocess  Communications 

(To  be  determined  at  a 


3.6.1  Block/Wakeup  Mechanism 

(To  be  determined  at 

3.6.2  Message  Segments 

(To  be  determined  at 


later  date.) 


a I ater  date. ) 


a later  date.) 
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3.7  Trustee  Processes  and  System  Functions 

(To  oe  determined  at  a later  date.) 

3.7.1  System  Control  Process 

(To  be  determined  at  a later  date.) 


3.7.2  Backup 

(To  be  determined  at  a later  date.) 

3.7.3  Retrieval 

(To  be  determined  at  a later  date.) 

3*7.4  The  System  Security  Administrator 

(To  be  determined  at  a later  date.) 

3.7.5  The  System  Admini strator 

(To  be  determined  at  a later  date.) 
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3.7.6  Maintenance  and  Repair  Processes 

(To  be  determined  at  a later  date.) 


3 .7.7  The  I/O  Coordinator 


(To  be  determined  at  a later  date.) 
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3«3  System  Audit 


(To  be  determined  at  a later  date*) 
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4.Q  Quality  Assurance 


This  section  does  not  apply  to  this  report. 
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5.3  Preparation  for  Delivery 


This  contract  only 
describing  the  deve 
the  demonstration  o 

None  of  the  har 
specification  or 
implemented  during 
Mu  I tics  are  to  b 
Honey we  I I . 


calls  for  the  preparat 
lopment  of  a prototype  se 
f its  characteristics. 

aware  modifications  des 
the  software  modific 
the  development  of  a 
e formally  delivered  o 


ion  of  reports 
cure  M jI tics  and 


cribed  in  this 
ations  to  be 
prototyoe  secure 
r supported  by 


* 
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6.3  Notes 


This  section  contains  information  which  is  not  contractual  ly 
binding#  It  will  be  filled  in  as  various  side  issues  of  the 
project  are  identified. 


r 
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